1. Field of the Invention
The invention relates to communication systems. More specifically, the invention relates to detecting responses from a modem system not supported by a usual data path.
2. Related Art
Communication systems permitting communications over phone lines via modems are generally well known in the art. More recently, other kinds of communication links, such as ISDN, have become common. So that application programmers need not be concerned with the physical communication layer, Application Programmer Interfaces (APIs) have been developed. Particularly, Microsoft has developed a telephony API (TAPI), which is widely used throughout the industry. Current versions of TAPI provide support for voice, data, and fax communication modes. Unfortunately, newer modes of communication, including for example, videophone mode are not supported by TAPI. It is expected that new modes will continue to be developed and accordingly, the case of ancillary modes will be of continued importance.
FIG. 1 is a block diagram showing layers and data flow in one example of a prior art system. A telephony dialer 1 sends commands to and receives responses from a TAPI module 2. A TAPI module 2 provides the commands to the telephony service provider (TSP) such as Unimodem.tsp 3. Unimodem.tsp 3 is provided by Microsoft Corporation. Unimodem.tsp 3 in conjunction with Unimodem.vxd 4 are the layers that actually talks to the communication device, whether it be a modem or, for example, an ISDN card. Unimodem.tsp 3 is specific to supporting communications over the telephone lines using a modem. Unimodem.vxd 4 translates higher level modem commands into the command strings for the modem being used. Virtual Communications driver 5 (VCOMM driver) reads and writes to the port in response to commands from Unimodem.vxd 4. The modem port driver 6 drives communications to and from modem 7 which supports videophone mode.
There are also existing videophone applications. Videophone application 8 communicates with a modem call control (MCC) module 9, a H324 protocol stack 10 and a V. 80 modem driver 11. To originate a videophone call on the local side of the connection. If the user decides to use the video phone mode, videophone application 8 sends commands to MCC module 9, which in turn disables telephony dialer 1 and TAPI module 2 as the videophone call will necessarily be handled along data path 23.
A problem exists because assuming that both the remote and local communication ends have the form shown in FIG. 1, while either side could originate a videophone call, neither side could recognize and therefore respond to an incoming videophone call. During a voice call established through TAPI, voice commands and events in a voice call follow data path 21 through each of layers 1-7. Data path 23 is disabled during a voice call. Thus, if a remote request to switch from video phone mode is received by modem 7, the modem 7 will recognize the request, but will wait for instructions from the host before switching into videophone mode. Thus, the request is forwarded up data path 22. When the request reaches Unimodem.TSP 3, Unimodem.TSP 3 will discard the request as an unknown string. Thus, it is not possible to establish a videophone link responsive to a remote request.
In view of the foregoing, it would be desirable to have a way to detect requests to transition into a mode not supported by TAPI. Videophone mode is merely one exemplary mode not supported by TAPI for which it would be desirable to detect requests.